This article was contributed by Tim Bergel in 2013.

*

I had relatively little experience with electronics before going up to Churchill college in 1975 but I had by that point become familiar with simple circuitry and had completed a number of more-or-less successful projects - the most interesting being a repetition of the Miller experiment which used a high-voltage spark in a sealed container to simulate very early conditions on earth and demonstrate the generation of amino acids - a necessary precursor of living systems - purely as a result of the high-voltage discharge. At Churchill I mostly studied the blological sciences but was friends with electronic engineers and physicists and I learnt more electronics from them. One of our more satisfying projects was a 6-channel FM intercom system that transmitted over the Churchill mains wiring. It showed a gratifying ability to jump across separate phases in the internal mains wiring, but imposed rather a large signal on the mains voltage which caused a friend's digital clock (that used a zero-crossing detector on the mains signal as it's master frequency) to run very fast - we had to build him a mains filter so he didn't complain.

I also encountered computers for the first time as part of a maths for biologists course but it was a very simple system which had very limited resources. Of course, all computers at this time were extraordinarily limited - I remember in my second year the main university computer was shut down for a week when it was upgraded with a third megabyte of memory which apparently arrived on a flatbed truck. Having passed the maths for biologists course I was able to get an account on the main university computer and did more programming. It was very slow work developing a program when it took three days to find out if the job had even run, and even then you mostly got a compiler error...

Also during my second year we started to hear about a strange new thing called a microprocessor which had been developed by a US firm called Intel. It was clear to me that a microprocessor was a sort of computer but I remember not understanding at all how this relatively simple bit of electronics related to the FORTRAN programs I had written. All this address and data bus stuff seemed a world away from variables and logical jumps.

MK14
While I was still at university early 8080 and 6800 kits had become available in the US but could not be obtained in the UK unless you imported them yourself. They were also too costly for our very limited resources. Then one of my friends found an ad for a thing called the MK14 in a UK electronics magazine. This was clearly very limited but available in the UK and much cheaper. I bought one and, with help, managed to get it working. Then came the rather longer task of working out how it worked which was a great introduction to microprocessors and assembly language. As I recall the owners manual included a full listing of the internal firmware or maybe we were able to obtain such a listing somehow. Its simplicity made it a great learning tool but even with the optional tape interface and expansion module it was very limited.

When I left Cambridge I got a job working for a year as an electronics technician in Oxford University Physiology labs. My main job was to provide computing support for the research group under Dr John Stein using various computers including a CP/M Z80 system from Research Machines. I also managed to make use of the MK14 (with further modifications and re-boxing), using it to control (via a pair of DACs) the position of a circle on a CRT screen, detecting (I don't recall how) when the subject (a monkey) had placed the tracking dot within the circle and giving a food reward if the tracking dot was on target for more than a second or so. I'm still amazed that I managed to get such a simple system to do something that was actually useful.

SIB
While still at Churchill my friends and I had discussed designing and building a more capable computer system of our own. This was to be called SIB (Small Is Beautiful). A major impediment to our initial design work was that new processors and systems were appearing so fast! When the 6502 appeared it was particularly attractive to us because of it was pretty-much a standalone system on just one chip with a very simple bus interface, so we fixed upon that. At least three separate SIB systems were developed but by that point we had left Cambridge and it was difficult to keep in touch, so the different designs pretty much went their own separate ways.

SIB hardware
My SIB system started out based upon hand made PCBs and was first just a single board system not unlike the MK14 but using a 6502 processor and a UV-erasable ROM so the firmware could be upgraded. The display was a row of 8 seven-segment displays but from an early stage it did at least use a proper keyboard that I had got hold of somehow. Other PCBs provided extra IO and a simple cassette tape interface and (I think) extra RAM. The main problem with this was that the PCBs were very large and extraordinarily labour-intensive to produce. I had to first design the circuits, then draw them out on a pair of sheets of paper to get the PCB design. Then a sheet of double sided PCB had to be marked out with the position of all PCB holes, the holes drilled-out with a fine hand drill, and finally the copper pads and tracks drawn in using a cellulose acetate resist. The PCB was then etched with ferric chloride, the bits where the etching did not work repaired with fine wire, through-hole connections and IC sockets soldered into place and then I had to get it to work... Once I tried a new fast etchant - a mixture of bleach and 50-volume hydrogen peroxide. It was certainly fast; removing all resist and copper in under 3 minutes and leaving a lovely clean bit of fibreglass with holes in it - two months work gone.

By this time I was working in Cambridge and had used wire-wrapping for prototyping work. I realised that this would solve a number of my problems - it was much faster, I could get a much higher package density and thus move to a more compact design and most importantly it was much, much, easier to correct errors in the boards when they were found. So I began a complete redesign and rebuild - first adding (finally!) a video card to the existing system - which kept me busy writing support software for some while, then steadily replacing the existing cards with wire-wrap equivalents - usually much improved designs. The processor was the last original card to go, which enabled me to switch to the rather elegant 6809 processor which provided significant 16-bit capabilities. Once all the cards were the much smaller wire-wrap type I was able to fit everything into a card rack I had scavenged from my job and generally tidy up the extra electronics and power supply.

Finally I was able to build an extra card that provided an interface to 5 inch floppy disk drives (which had to be imported from the USA at great cost but at least cheaper than buying them in the UK) storing 360 Kbyte per disk. The controller chip was very easy to use and I was able to add simple disk read-write routines to the ROMs and finally dispense with the cassette tape. That more or less was the end of my SIB hardware development.

SIB software
The initial SIBMON design accepted single character commands with optional 2- and 4-hexadecimal character parameters to provide a very simple monitor allowing memory to be inspected & changed, and also allowing functions at specified adresses to be called. Though simple it was still quite difficult to get running at the start; I had to first write the code, then enter it into memory on the MK14 and use code on the MK14 to blow the code into an EPROM. Then I plugged the PROM into SIB, turned it on and watched what happened. As the initial SIB hardware contained a number of faults initial debugging was done using an oscilloscope - the first code simply repeatedly read data from address 0 and looped back and getting that to both run and execute the read allowed me to worm out most of the hardware issues. Then I could start writing preliminary monitor code and trying that out, the only thing that made this even slightly straightforward was the fact that I could use the MK14 to enter 6502 code & blow it to EPROM, and also save it to MK14 tape so it could be retrieved and modified later. Thus bit by bit I got a primitive monitor working and displaying memory on the 7-segment displays.

Once I had that code working I then had to write functions to program data onto an EPROM and append that to the back of the existing monitor. I got that right first time! Getting a primitive tape interface working plus read & write functions were not too hard either and then I had everything I needed to move on without the MK14. Code development was primitive. I had to write code as assembler, then convert the assembler mnemonics to machine code by hand - I got to the point when I could carry out an 8-bit hexadecimal subtraction in my head - using work sheets that I photocopied. That was all very well but all linkage had to be done by hand and as a number of bits of code might reference a function at address XXXX it was necessary that the function entry point did not change if at all necessary. Nowadays I would use a jump table to allow a change in a function address to be easily accommodated - at the time I just made sure there was spare space between functions so that extra code could be added. It could get messy - when I rewrote SIBMON to use the CRT display (25 lines of 80? characters) a great deal of new code was needed. I think I started off with a separate EPROM with a collection of utility functions which I could use in the developing monitor and then had to painstakingly stitch it together into a functional monitor in a single ROM.

Once I had a working floppy disk interface it became a lot easier to work on the software because I could at least take quick snapshots of work in progress. Also by that time I had switched to the 6809 processor, with which it was pretty easy to write position-independent code. Things were clearly getting easier but I was running into the limits of the software I could develop myself - I didn't have the time to write a floppy disk directory system - so I kept track of what data was where on the disks using a hand-written directory in a book.

Enter Flex-09. Flex-09 was a straightforward DOS rather similar to CP/M which made use of IO functions in a ROM that functioned as a BIOS. Being a DOS it included floppy disk directories so we had files at last, plus a fair amount of useful software. I cannot remember how I got hold of an OEM copy of Flex but it was, I think, bought fairly cheaply or even given away for the cost of duplicating the manual. As SIBMON already contained a good collection of position-independent I/O routines it was remarkably easy to restructure the EPROM so that SIBMON still existed, but in a Flex-09 compatible manner and then to add code to boot Flex from floppy disk. I don't recall what I had to do to connect Flex to the EPROM BIOS functions - I think I had to patch a table held at the end of the floppy disk boot sector with the function entry points. Getting Flex-09 running was fantastic for software development - at last I had an assembler so I didn't have to do all the machine code translation by hand!

Tim Bergel. Senior Programmer at Cambridge Electronic Design Ltd. March 2013